1. Field of the Invention
The present invention relates to managing, scheduling and initiating videoconferences.
2. Discussion of the Background
Conventional videoconferencing systems comprise a number of end-points communicating real-time video, audio and/or data streams over and between various networks such as WAN, LAN and circuit switched networks.
A number of videoconference systems residing at different sites may participate in 10 the same conference, most often, through one or more MCUs (Multipoint Control Unit) performing via switching functions to allow the audiovisual terminals to intercommunicate properly.
As videoconferencing involves various recourses and equipment simultaneously interoperating at different localizations and capabilities, there is a need for the possibility to manage the resources involved both for scheduled and ad hoc videoconferences.
Videoconferencing systems are therefore often provided with a management system. A management system is a module that is used to schedule or book resources at any given point in time. The management system will allow a user to request resource usage at a given time, and either allow or disallow the usage at that time. Management systems are often used for scheduling the use of meeting rooms, network resources, video systems etc. The management system must be connected to a database containing updated information regarding all accessible resources like MCUs, gateways, routers, end-points etc.
A management system may for example provide system and resource overview, allowing the user to create, edit, and delete reservations, reserve resources for dial-in participants and specify bandwidth and network settings. The management system may also support automatic call routing and automatic selection of point-to-point connection, including one or more MCUs. The management system normally operates with an intuitive web interface requiring no additional installation on the user terminal other than a conventional web browser.
Even if users have audio or videoconferencing equipment available, either as personal or group systems, a large problem with scheduling meetings using audio and videoconferencing equipment is knowledge of which resources are available to a given participant. In many cases, it is necessary for the one that is booking the conference to ask the participants in person about which localizations and systems etc. are accessible to them at the particular moment, and which accessories and services they have available or which is preferable. This manual “round-robin” request is added to the use of a management system, causing delay in conference booking and reducing the utilitarian value of the management system. The lack of knowledge regarding the participants' access and preferences is also the main reason that ad-hoc conferences are difficult to set-up—they simply require too much fluctuating knowledge of the far end side from the users.
Another problem regarding ad-hoc scheduling is that even if the management system knows that a certain end-point is available and ready for use, it cannot know whether the participants are present at the different sites, when the videoconference is not pre-scheduled. Ad-hoc booking will then normally also require manuals requests in the form of additional calls to the participants in advance, making it behave like a pre-scheduled call.
These problems are now more often met by connecting the management system to a presence application. Presence applications are known as applications indicating whether someone or something is present or not. A so-called “buddy list” on a user terminal shows the presence of the people or systems (buddies) that have been added to the list, The list will indicate if the “buddy” is present or not (logged on the computer, working, available, idle, or another status). The presence functionality creates a feeling of presence also with people or things that are located in other buildings, towns, or countries.
Presence applications are often found in conjunction with Instant Messaging (IM) applications. These applications extend the presence application by adding the possibility of exchanging information between present “buddies”. The information exchange may include applications like chat, messaging and conferencing.
In Presence and IM applications, there is a central server keeping track of all the clients in the system, while the client provides the server with information about their own state and location. The server also handles user login and provide information of the “buddies” in respective “buddy list” by using a proprietary protocol. However, information between clients (“buddies”) may be transmitted directly as the server provides connection information (IP address and port number) of the client's “buddies”.
Conventionally, the protocol used in the application layer of IM communication is SIP (Session Initiated Protocols). SIP is an Internet Engineering Task Force (IETF) standard protocol for initiating an interactive user session that involves multimedia elements such as video, voice, chat and gaming. SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are identified by SIP URIs. Requests can be sent through any transport protocol, such as UDP, SCTP, or TCP. SIP determines the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination. As already indicated, SIP requires a central server i.a. for signaling, registration and policy handling. Such SIP servers are usually integrated with the presence server mentioned above in connection with presence and IM applications. Microsoft Live Communications Server (LCS) is an example of server software for presence and IM applications, where users can send instant messages and communicate using web cameras through an IM client such as MS Communicator or Windows Messenger.
The connection between the presence application and the management system may appear for the users in many ways. The most convenient would probably be to integrate the management system in the IM/Presence application or vice versa. Hence, allow the user to see the presence of both the user and system. A double click on a “buddy” in a “buddylist” may e.g. execute an immediate initiation of a call set up to the “buddy” using the most preferred idle system associated with the “buddy”. A click on further “buddies” preferably includes them in the call constituting a conference, all provided by the functionalities already available in the management system. The management system may be instructed by requests from the presence application using the proprietary protocol.
However, management systems and IM applications are developed for different purposes and uses different protocols. The integration of these different “worlds” often requires non-proprietary solutions and additional processing power. This is an obstacle for interoperability between vendor products, which again is an obstacle for the penetration of communication applications.